Traditionally, the system behavior are modeled in two different approaches. One focuses on internal active activities that a system performs, whereas the other focuses on behavior reacting to external events. This two-prong approach is reflected by the fact that Activity diagram, which focuses on active behavior, and Statechart, which focuses on reactive behavior, are two different styles of diagrams in United Modeling Language (UML). Let's call the former approaches “active behavior modeling” and the latter ones “reactive behavior modeling”.
Active behavior modeling includes flow chart, Business Process Modeling Notation (BPMN), XML Process Definition Language (XPDL), Business Process Execution Language (BPEL) and UML Activity diagrams. Both BPMN and UML Activity diagram use nodes in a diagram to represent activities to perform, while using links to connect one node to another representing the sequence of these activities. On the other hand, XPDL and BPEL define these activity nodes and their links in an eXtensible Markup Language (XML) syntax instead of a diagram.
While these active behavior modeling notations are useful in describing internal active behavior of a system, they are inadequate for defining reactive behavior in response to external events that may occur at any time. A typical approach is to have some special event detecting activities, such as “receive” in BPMN and BPEL, to detect these possible external events. Since external events can happen any time, various event detecting activities have to be inserted in various places in a diagram. However, unlike a state machine, these active behavior modeling diagrams don't have a “state” where all event detecting activities can be grouped together. The result is that these event detecting activities are scattered all over the places in a diagram and makes it very difficult to know what external events an application system is waiting for at any point in time during execution.
A major drawback of this approach is that if a correct detection activity is not inserted in a critical position in a diagram, some unexpected events will be left unprocessed and the application system may crash at run time. To overcome this problem, a designer may try to place various event detection activities all over the diagram. The result may be an overly complex diagram.
Another drawback is that since these event detection activities are inserted in a diagram in an ad hoc and unstructured way, it is very difficult to verify if the system behavior as defined in the diagram is consistent with other systems that it communicates with. This deficiency has caused many critical design problems with an application system that needs to interact with other systems.
While an active behavior modeling notation fails to provide an adequate facility to support reactive behavior in response to external events, a reactive behavior modeling notation is designed specifically to address this issue.
Reactive behavior modeling includes finite state machines (FSMs), UML Statechart, and Dynamic State Machine. A pure FSM includes a number of states and their outgoing transitions with external events clearly specified for each transition. While at a state, the FSM is waiting for all possible external events. Upon receiving a valid external event, a transition is triggered and an associated action is performed along with the transition. After a transition, the current state becomes inactive, and another state becomes active. The FSM then waits for another set of events associated with the new active state. Therefore, at any time, a FSM typically is in a particular state waiting for various possible external events to happen.
A pure FSM has a number of disadvantages. For example, one undesirable restriction is that a pure FSM has no memory. Due to its lack of memory, the usage of a pure FSM is very limited. Since a state in a pure FSM contains no memory, any change or information about history, such as a simple counter, must be presented by defining additional states in order to maintain these changes. Given the infinite number of values that a counter may have, an infinite number of states would be required.
Extended finite state machines (EFSMs) or Register Automata add memory or data variables to each state to contain values, such as numbers and counters, to overcome the major problem of a pure FSM as described above. EFSMs are widely used to model various reactive systems.
When EFSMs are used to model some real world events or behavior, it is often found that a hierarchical of states or nested states are useful to reduce the number of states and to organize a complex set of states into a hierarchy. Statechart as part of the United Modeling Language (UML) and STATEMATE are some examples. Statechart is the term used herein to refer to a hierarchical finite state machine.
Although a reactive behavior modeling notation is design to deal with external events, it typically overlooks how to specify complex internal active behavior. As we have already learned from using some active behavior modeling notations, these internal active behavior can be extremely complex. It would be highly desirable to incorporate an active behavior modeling notation that is consistent to the reactive behavior modeling notation.
Another common deficiency shared by existing active and reactive behavior modeling notations is that they can only specify the behavior of a single system. Complex internal messages exchanged among components inside of a super system are not modeled in any way. The lack of support for behavior of multiple parties is very limiting in a distributed computing environment where a system may contain multiple sub-systems who communicate with each other to coordinate their work.
What is needed is a comprehensive approach to unify both active behavior modeling and reactive behavior modeling notations in a single consistent modeling notation that also supports dynamic behavior of multiple parties in the modern distributed computing environment. The present invention provides such a solution.